Integrated composite data base system 



The invention relates to the integration of different 
structurally incompatible data base systems. 

Data base systems play a large part in numerous 
applications in electronic data processing. They 
usually comprise the actual data base and a data base 
management system. They are often the foundation for 
extensive computer applications in which the data 
stored in the data base are processed further in a 
variety of ways. 

An important example in the area of company EDP are 
' ERP ' (enterprise resource planning) systems, such, as 
OLTP-R/3 from SAP AG, Walldorf, Germany. They permit 
EDP support for a very wide variety of company 
divisions, such as "personnel, sales and distribution, 
storage, etc., on the basis of a common central data 
base. Such systems are commonly called "back-office 
systems" . 

Another important example of data base systems are 
customer support systems, which are commonly called SFA 
(sales force automation) or CRM (customer relation 
management) systems. Such systems are tailored 
especially to the EDP requirements of customer advice, 
customer support, and sales and distribution. This 
allows for sales representatives of the company to be 
equipped with a portable computer which, as a 'mobile 
client' of the data base system, provides an individual 
local data base containing the data required by the 
respective sales representative (for example relating 
to the customers from his area or to the status of the 
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sales which he has made) . Such a system (which is 
commonly called a front-office system) has an 
associated central computer which likewise contains a 
data base storing all of the data of the mobile 
5 clients. Hence, this is an offline-distributed data 
base system. Besides the mobile clients, other external 
systems can also communicate with the central computer 
of the CRM system, such as customers' EDP systems, 
which are connected to the central computer via 
10 temporary or permanent data links. 

Both customary back-office systems and customary front- 
office systems are extraordinarily complex. They each 
require powerful methods to ensure that the various 
15 components are able to communicate, to ensure data 
integrity and data synchronization, bearing in mind 
that communication can involve very large numbers of 
users . 

2 0 While these problems have largely been solved for 

extensive systems of the aforementioned type, there are 
still no convincing procedures for combining together 
data base systems which are structurally incompatible 
but largely manage the same (business) data. By way of 
25 example, ERP systems normally store extensive datasets 
relating to the company's customers (e.g., addresses, 
contacts, data relating to finished orders, purchasing 
conditions, or else the customers' machine equipment, 
which is important for the supply . of replacement 
parts) . Largely concurrent datasets are also required 
in CRM systems. In practice, however, the two systems 
have a very different, mutually incompatible data base 
structure . 

3 5 By way of example, pricing is a task which is performed 

in different applications with the assistance of EDP. 
Although a standard business procedure (for example 
taking into account the production costs, the quantity, 
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a) 



b) 



the primary key for data objects which are to 
be transported from the source data base system 
A to the destination data base system b is 
compared, using a primary key generator, with a 
key mapping table which contains the primary 
keys for all data objects for which both 
primary keys have already been generated- 
if the primary key is not yet available' in the 

dIsfT Ping t3ble ' a ' Prim *^ key of the 
deStlnatl ° n data base ^em b is automatically 
created, is stored in the data object and is 
stored in the key mapping table KMT together 
with the primary key of the source data base 
system A; 

15 c) if ^ primary key of source ^ ^ 

system A was found in the key mapping table 
the corresponding primary key of the 
destination data base system B is stored in the 
data object. 
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m accordance wl th a second aspect, the object of the 
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the data base systems are processed in the form of data 
objects which each contain a system-specific primary 
key and the data in the second data base system B are 
stored with the two system-specific primary keys, in 
which at least some of the following procedural steps 
are carried out: 

a ) the data D R/3 which are not relevant to the 

second data base system B are removed from the 
data object; 

b > the data object is transferred from the first 

data base system A to the second data base 
system B; 

c) a key which is specific to the data base system 
B is created, and the created key is added to 
the data object, and 

d) the data object produced is put into the 
storage routine of the second data base system 
B, and the data contained in the data object 
are stored in the data base of the second data 
base system B. 

Preferably, all of steps a) to d) are carried out. 

In accordance with another aspect, the object of the 
invention is a procedure for updating the dataset in a 
first data base system A as a result of ^changes which 
have been made in the dataset in a second data base 
system B, where the dataset of the second data base 
system B contains both data which are not relevant to 
the first data base system A and data which are 
relevant to the first data base system A, the data in 
the data base systems are processed in the form of data 
objects which each contain a system- specif ic primary 
key, and the data are stored in the first data base 
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system A only with the system- specif ic primary key 
thereof, in which at least some of the following 
procedural steps are carried out: 

5 a) the data D MS which are not relevant to the first 

data base system A are removed from the data 
object, and these data are parked in the second 
data base system B; 

10 b ) the data object is transferred from the second 

data base system B to the first data base 
system A; 

c) the system-specific key for the second data 

15 base system B is removed from the data object, 

and this key is parked in the first data base 
system A; 



20 



d ) the data object produced is put into the 

storage routine of the first data base system 
A, and the data contained in the data object 
are stored in the data base of the first data 
base system A. 

25 Preferably, all of steps a) to d) are carried out. 

In accordance with yet another aspect of the invention, 
a procedure is proposed for entering or changing data 
in a composite system comprising a plurality of data 

30 base systems, in which, to prevent data conflicts in 
the context of the shared new entry of data in any one 
of the data base systems in the composite system, one 
of the data base systems is defined as managing system 
FS for each data object which can be interchanged 

35 between the data base systems, and, for each new entry 
or change in a managed system GS of data in the data 
object which is also part of the dataset of the 
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managing system FS , a cross-system confirmation 
algorithm is executed, in which 

a) a data object containing the change is trans- 

5 ported to the managing system FS, 
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b) 



c) 



the managing system FS creates an acknowledge- 
ment in the form of a confirmation or at least 
partial rejection of the change, and 

a data object containing the acknowledgement is 
transported back to the managed system GS . 
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The invention is explained in more detail below with 
the aid of exemplary embodiments illustrated in the 
figures. The special features described therein may be 
used individually or in combination with one another in 
order to provide preferred embodiments of the 
invention. In the figures: 

Figure 1 shows an overview of the environment of an 
inventive composite system of offline- 
distributed data bases, 

Figure 2 shows an overview of the architecture of a 
front-office system used within the context 
of the invention, using the example of a CRM 
system, 

Figure 3 shows a typical procedure in the flow control 
of the system shown in Figure 2, using the 
example of a data-upload event, 

Figure 4 shows the structure of data objects ("BDocs" ) 
used in the system shown in Figure 2, 

Figure 5 shows the architecture of the components 
which are effective in two systems, linked to 
one another in accordance with the invention, 
during the upload and delta download of data, 

Figure 6 shows a flowchart in line with Figure 3 for 
the case of a delta download, 



Figure 7 shows the architecture of the components used 
for initially downloading data to one of the 
data base systems involved, said data being 
contained in the other data base system, 

Figure 8 shows a basic illustration to explain a 
procedure for providing the necessary primary 
keys across the system, 

Figure 9 shows an example of the segment structure of 
a BDoc and of the associated key mapping 
table, 

Figure 10 shows an example of the structure of a BDoc 

based on Figure 9 with a somewhat more 

complicated segment structure, 
Figure 11 shows an illustration to explain the 

principles of a data-merge procedure suitable 

for the invention, 
Figure 12 shows a basic illustration of the interaction 

of the most significant components during 

initial download, 
Figure 13 and Figure 14 show two illustrations to 

explain a net-field-transmission procedure 

suitable for the invention, 
Figure 15 shows a basic illustration of the fundamental 

components for explaining a data- 
synchronization procedure, 
Figure 16 shows a basic illustration to explain the 

operation of a "Compare" module suitable for 

the invention, 

Figure 17 shows a basic illustration of a procedure, 
suitable for the invention, for resolving 
conflicts upon data update. 

The application illustrated by way of example in the 
figures, involving an inventive integrated composite 
system, relates to the integration of a sales and 
distribution EDP solution (Sales Force Automation; SFA) 
with a central ERP system. Figure 1 provides an 
overview of the environment of such a system. 



Employed in the field FD are sales representatives SR 
who advise the customers C and take their orders, for 
example. Each sales representative SR has a portable 
computer, which is also called a mobile client MC and 
has an associated local data base LD. The portable 
computers form nodes in a network which are not 
continuously linked thereto and are therefore called 
offline nodes. 

By way of example, the mobile clients MC provide 
marketing information and store, amongst other things, 
the master data for customers and products. The sales 
representative SR can enter order information, for 
example, and is informed of the status of open and 
finished orders. In order to be able to perform these 
functions autonomously on a temporary basis, all the 
data required for this purpose are stored in the local 
data base LD. 



The head office HO of the company contains a back- 
office system which preferably permits online 
transaction processing. In the illustrative case shown, 
it is an OLTP-R/3 system. It is denoted by this term in 
the drawings and in the text below without any 
limitation of the general nature. It contains a data 
base OLTP-DB . Its master data are maintained by in- 
house employees IHE. 

A local area network LAN connects the OLTP-R/3 system 
to a front-office server which is called (MS middleware 
server), likewise without limiting the general nature. 
This system also has a data base (consolidated data 
base) CD. 



can 



Besides the mobile clients MC, other systems 
optionally be linked to the MS system. The figure shows 
an external system BW located in the head ' of f ice HO, 
said external system supporting the analysis of 
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significant sales information for the company, for 
example as a "Business Information Warehouse". It has a 
data base BW-DB. In the case illustrated, it receives 
data both from the back-office server OLTP-R/3 and from 
the MS system. In the field FD, customer systems CS, 
for example, which form additional nodes in the 
network, can be linked to the MS system continuously 
(online) or temporarily (offline) . In this manner, by 
way of example, direct orders from the customers can be 
processed without the involvement of a sales 
representative SR. The customer system CS also has a 
data base CS-DB. 

The network shown thus contains different data sources 
(mobile clients MC, OLTP-R/3 system, optional external 
systems BW and customer systems CS) , but these are not 
independent of one another. They are linked by the MS 
system, which ensures that each subscriber receives the 
information which he needs and for which he is 
authorized. In the case shown, the middleware server MS 
simultaneously performs this linking function and forms 
the central computer in a CRM system, which comprises 
said central computer and the mobile clients and is an 
offline-distributed data base system. This system is 
fused with the central data base system OLTP-R/3 . The 
principles of the present invention can also be applied 
to other cases of data base systems being combined, 
however, that is to say, in particular, to the 
combination of two or more central data base systems or 
to the combination of two or more distributed data base 
systems. 

The data base MS-DB of the MS system contains all the 
information required for its special function (in the 
illustrative case, customer relationship management 
CRM) . It is also called a consolidated data base CD, 
because it contains the content of all the local data 
bases LD of the portable computers (at the instant of 
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processing requests. The machine on which the message 
transfer server is running is called the admin station 
AS as a whole. The message transfer server MTS and the 
associated admin console AC are preferably installed on 
a machine running under Windows NT. The resultant 
possible machine boundary is shown by a dashed line in 
the figure. 

The data in the front-office system are transported 
using data containers called BDocs . These are also used 
for communication between the mobile clients MC and the 
MS system. In this context, a distinction can be drawn 
between various types of BDocs: 

Transactional BDocs are used for transmitting 
transaction results and status information between 
the portable computers MC and the front-office 
server CRM-MS. They can be distinguished further 
as follows: 

Transaction BDocs transport transaction results 
from the mobile clients MC to the MS system. In 
this case, the mobile client forms a BDoc 
containing the result of the transaction and sends 
it to the MS system. 

Confirmation BDocs indicate successful processing 
of a transaction BDoc by the MS system. If the 
processing of a transaction BDoc has been 
successful, the status of the ' BDoc is changed 
accordingly and the BDoc is sent back as 
confirmation message to the mobile client from 
which it was sent. This confirmation message also 
contains additional data, which have been made 
: available by the OLTP-R/3 system, for example, or 
changed values of the consolidated data base CD. 
In this context, the confirmation BDoc contains 
either only the changed values or all the values. 
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. - -star process" rtrrnVrrn For . the — 

' « read from lookup tables \7 t 2 "T.™" '~ tMS 
establishes that the . replication part 

— - accounttf a^c ^ "T* * - 
messed. it triors the 
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realxgnment handler creates the necessary lookup 
information by evaluating the replication rules m 
addition, the realignment handler provides new data for 
receivers and gives instructions for deleting data 
whxch are not needed. For this purpose, it uses the 
extract handler. 
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The administration console AC is used for customizing 
the MS server and for administering the entire system 
xn terms of the logical flow of data. 



Figure 3 uses the example of a data upload operation to 
show a typical procedure in the flow control of the MS 
system. The column headed MP-FC in the figure shows the 
steps carried out by the message processor MP in the 
flow control FC . The first and third columns show the 
processing steps carried out by services. The last 
column indicates processing steps which are carried out 
by the OLTP-R/3 system. 

The flow begins when the message transfer server MTS 
calls the inbound message adapter IMA (using RFC) 
because a new BDoc has been received. The inbound 
message adapter IMA starts the message processor MP-FC. 

The flow which is to be executed is determined by the 
message processor MP. m principle, a distinction can 
be drawn between two flow procedures, one for 
Processing BDoc types which are at least to some extent 
30 relevant to the OLTP-R/3 system, and one for other 
BDocs (circulating only within the MS system) . 

On the basis of the flow definition stored in a 
repository for the respective BDoc types, the message 
Processor MP determines the f irst service Qr adapter 
whxch is called. For types of BDocs which are (at least 
to some extent) relevant to the OLTP-R/3 system, the 
fxrst service called is the OLTP-R/3 adapter OLTP-AD 
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For other BDocs, the OLTP-R/3 adapter is not called 
The decision of whether the OLTP-R/3 adapter is to be 
called for a type of BDoc has been made during 
definition of the flow, that is to say, is not made 
5 while the flow is occuring. 

When the OLTP-R/3 adapter OLTP-AD has been called it 
determines whether the BDoc is actually relevant to' the 
OLTP-R/3 system. This is not necessarily the case 
10 because relevance to the OLTP-R/3 system does not 
depend only on the type of BDoc, but may also depend on 
its content. One example are BDocs of the business 
object type "customer-. if such BDocs . contain 
information relating to customers, they are sent to the 
OLTP-R/3 system. If they contain information relating 
to sales and distribution contacts, however, they are 
stored in the MS system only. 
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When the OLTP-R/3 adapter has established that a BDoc 
« relevant to the OLTP-R/3 system, it sends a call 
thereto and interrupts the flow in progress. Once the 
processing in the OLTP-R/3 system has been stopped, the 
OLTP-R/3 system sends a call to the OLTP-R/3 adapter 
which receives the result and restarts the flow by 
callxng the message processor MP in the flow control 
FC . 
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The message processor MP-FC ascertains which service 
needs to be called next, if the OLTP-R/3 adapter OLTP- 
AD has established that the BDoc is not relevant to the 
OLTP-R/3 system, it returns control to the message 
Processor MP-FC, which also determines the next service 
whach needs to be called in this case. 

OLtTr^' T baSS SSrViCe CDS ±S CallSd ^e 

OLTP-R/3 adapter. The data base service preserves the 

Zsl c C D ° ntained in thS BDOG in ^ consolidated data 
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When the data has been successfully written to the 
consolidated data base CD, the replication and 
realignment service RRM is usually called. A function 
of this service is to check whether the BDoc influences 
the replication information, if this is the case, an 
order is created for the realignment handler to update 
the lookup information and to create a BDoc for 
distributing the business data. The second action of 
the replication and realignment service RRM is to add a 
receiver list to the current BDoc. 

Finally, the outbound message adapter OMA is called to 
prepare the BDocs for transfer to their receivers by 
means of the message transfer service MTS . 



If the upload fails, a reject service RS is called. The 
BDoc is marked as an error BDoc (that is to say as a 
BDoc which contains error information) . During the 
update operation, the reject service reads the valid 
values from the consolidated data base CD. During all 
operations, the respective previous states of the 
mobile clients MC are marked. The BDoc is then sent 
back to the portable computer from which it was 
transmitted. There, the appropriate transaction is 
25 executed again. 

Figure 3 shows - with the. exception of the reject 
service RS - only the success path. Naturally, an error 
Processing routine is also provided, although not 
described in more detail here. 



In Fl gure 4, the structure of the Bdocs is exolained in 
more detail. The top part of the fi gure shows the 
structure of the BDoc type's definition, which is 
35 stored in the repository of the MS system. The 
structure, which is likewise stored in the repository 
of the BDoc itself is shown in the bottom part 
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The BDoc comprises the BDoc header BDoc-H and the BDoc 
body BDoc-B. The BDoc header BDoc-H contains control 
information, such as the type ("customer", "order", 
...) of the BDoc, the sender thereof (mobile clients 
MC) and a time stamp. For performance reasons, it is 
advantageous if it also contains a duplicate of the 
primary key. 

The data are contained in the BDoc body BDoc-B. A data 
record DR contains the actual data. The structure is 
defined in the definition of the associated data 
segment DS . The segments form a type of tabular view 
for the actual physical tables. Optionally, the BDoc 
also contains an error segment ES having one or more 
error records ER. 

The data areas have a stipulated length. They comprise 
a key and data fields. If they contain a deletion 
information item, only the key field contains valid 
data. If they contain "insert" or "update" information, 
either all the fields contain valid data or unmodified 
fields contain a preset value (for example 0.0). To 
indicate whether a field is filled or unused, "send 
bits" are used. Primary keys and fields which need to 
be taken into account for replication and realignment 
are always sent (irrespective of whether they have been 
changed) . Send bits are set only if the value has 
actually been changed. 

The definition of the BDoc type, that is to say the 
information item relating to the structure comprising 
hierarchically arranged elements which is specific to 
the respective BDoc type, is contained in the BDoc type 
definition, which comprises a BDoc body definition 
BDoc-BD and BDoc segment definitions BDoc-SD. The BDoc 
body definition BDoc-BD contains precisely one root 
segment containing only a single data record. This 
condition needs to be observed in order to ensure that 
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the information contained in the BDoc can be 
individually transferred to the respective node systems 
or can be processed in another manner. By way of 
example, a BDoc of the "customer" type can store only 
5 information relating to a single customer so that the 
customer information item can be supplied to the 
appropriate node systems individually and specifically 
for each individual customer. The data records of 
segments arranged afterwards contain dependent data, 
10 for example relating to the customer's machine 
equipment. In this case, it is naturally possible for a 
plurality of records to be available for one segment. 

Whereas the segments in the definition of the BDoc type 
15 are hierarchically structured, there is no such 
hierarchy for the physical reproduction of the BDocs. 
The hierarchical dependency is contained in the BDocs 
by virtue of the data records DR of dependent segments 
containing the key for their superordinate data 
20 records. In the case of transactional BDocs, an 
independent segment is also (apart from the optional 
error segment ES with error record ER) provided, which 
is called a root segment. 

25 When changed data are transferred to the MS system, the 
values which the mobile client MC had before the change 
may be of interest to the MS system. Such "images of 
the preceding state" (before images )~ are transferred to 
dedicated data areas which are appropriately flagged. 

30 - 

Service-oriented BDocs are used to transfer data of the 
external system BW and installation files to a mobile 
client MC. The body of a service-oriented BDoc 
comprises a root segment, having general inf ormation, 
3 5 and a memo segment, which contains the binary data. 

Bulk-oriented BDocs are used for the initial setup of a 
mobile client (initial client setup) and for data 
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transport during realignment. Bulk-oriented BDocs are 
also defined on the basis of specific type (that is to 
say for the "customer" object type, for example) . 
However, they are not subject to the restriction that 
5 their root segment can contain only one record. By way 
of example, a bulk-oriented BDoc can thus transmit the 
data for a multiplicity of customers at once. 

The OLTP-R/3 adapter OLTP-AD links the OLTP-R/3 system 
10 to the MS system. It is used to transport data in both 
directions. When data, for example the order from a 
customer, are input into the mobile client MC and are 
then forwarded to the . OLTP-R/3 system, this is called 
an "upload" . When data are input into the OLTP-R/3 
15 system and are forwarded from there to the MS system, 
this is called a download. 

There are three distinguishable types of downloads. An 
initial download is used to fill the MS system's 

2 0 consolidated data base CD with data from the OLTP-R/3 
system at the start of operation. A delta download 
takes place when online users input data into the OLTP- 
R/3 system and the changed object is forwarded to the 
MS system. Such a delta download is not possible for 

25 all data types. If this function is not available, a 
third download mechanism is used, which is called 
synchronization mechanism below. 

The MS system's and the OLTP-R/3 system's components 
30 which are effective for the upload and 'for the delta 
download are shown in Figure 5. Component parts of the 
MS system are the flow control FC for coordinating the 
process steps required for processing the BDocs, the 
OLTP-R/3 adapter OLTP-AD, and also three agents called 
35 key generator KG, mapping agent MA and merging agent 
MEA. These agents perform auxiliary functions for the 
OLTP-R/3 adapter. 
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One component part of fh. MO 
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of the BDoc is mapped ontr, ,u 

^ a Ppropriate BApj nt ° Parameter structures of 

calling frame of 0 LT P- R/3 system _ 

R/3 system. 1S then c ^Hed ia the 

A first task of the call' 
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The main function of the 
. the standard B API SB . For CF is *° call 

' frame contains all the informal PUrP ° Se ' the call "9 
°roer to convert the struct^ T *' in 

mto the structure of the * BD ° C received by it 

«X processes the 

to update function modules u™ ^ ca "s 
bagin their work when the cam T 

command to the standard B API 1*™" ' °°™<^ 

-dules preserve the data chano fUnc «- 
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In the MS system, a result 

receive, re s ul ts bac k into B L "ruT" "* 
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10 above with reference to Figure 3 ^ *** ^-tions 
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then transferred to the MS . „ ubTp - R/ 3 system and is 
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control during processing of a ^ «~ 
"eated as a result of " haS been 

architecture is equivalent to Figure^ d0 ™ l0ad ' Th * 

20 The in-house employee the ^™ 

H/3 system online Ln^^"" 1 "" ^ ^ 
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download is necessary. The business . . ' 
which are to h« * , ess object classes 

be downloaded are det-*™- * 
customization of the svstPm T ' determined during 

particular attribute values. Finally " °" ° £ 
use specific exits (customer ex± ^y- " rs possible to 

Figure 7 shows the architecture of the 
<°r the initial download . An UL^ T^ 
^ent IDTA is started by th T s vst 
before the production phase be g ins 

-rtrate initial download. The initial do , 7 *° 
asent calls an OLTP do^load t^L, 
ferine is effected b y m eans o tTs" ^^"^ 

that the initial download action I! . "™ 

Precisely once. The OLTP download trio ^ 
calls extractor asters EM f or sel ^ ^ 

business objects sa i„ f sele «ed classes of 

-eir part. ^ L^^^ — g. ^ 
™ an extractor .aster EM and an IxtreLor ^t""^ 

extractor .aster is a component which rs " * 
surted to cooperation with the MS^ system 
extractors EXT are also used in L the 
OLTP-r/3 system hSr c ° nc ^ts in the 

25 

On the basis of the fiu„ 

^tractor masters. t^t^^T *~ 
data from the OLTP data base OLTP db t 
extractor master also = , OLTP-DB. m addition, the 
30 tables which are to be "—ting to 

do not b ? th - c °— 

respective extractor master !• , Erected. The 
objects to the „, ,? transfers the selected 

tne results sender bo , 
specific exits can be used to mentioned. 
35 filtering in . the results s"der °" s^ditional 

The results sender rc ^ 

data to the BAPI result ™ nSterS the business object 

result save agent PSA. The BAPI result 
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save agent calls the agents for the mapping ma, £or the 
*ey generation KG and a bulx storage agent for the 
consolidated data base ,bulx CDB agent, BCA The 
mapping agent converts the structures of the OLTP-R/3 
5 system into structures of the Ms system. The 12 
generator creates «s Keys for those objects which have 
only an OLTP-R/3 kev TH« k i t, . ave 
^ . Ulk stora 9e agent BCA writes 

the data of the business objects to th* writ ^ 
rf3 . a , „ Jeccs to the consolidated 

data base DB. The difference between the bulk storage 
10 agent BCA and the data base service CDS of 7 

system 1S that the fQrmer , s ^ MS 

Plurality of obiects *t- «->, Process a 

la . f objects at the same time, whereas the 

latter is able to process only data of • * 

business object in each case individual 

15 

To ensure good performance, a plurality of classes of 

business objects are downloaded at the same ti me 

clTs^I'of b- ^ MtUally dependent 

20 Tr e ° P r e tLder:. ob r s . d T d on other obj ~ ts 

, ^ oraers on "customers"), thev S r a 

downloaded successively in an appropriate order In 
this context, the objects are not downloaded 7t the 
level of instances, but rather at the level of classes 
^ in order to be placed in the desired order. 

applicatiV^Tfor^rr/ 1 - — ^ «*~ 
BW ). example an external application 

30 

extractor. This extractor Z^J'Z tyT £ " 

called SteP ' Che e "-«or master EM is 

called using the key list, in order to read th» . \ 
information. The the actua l 

extractor master uses the extractors 
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to fetch the data S npHf,'=^ • 
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y ' c - na ^ is to sav is flhio 
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The key generator KG is used to fi„* 
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30 unique identifiers) for „!, ,9l ° bal ly 

The necessary MS a aV " labl * °^P-R/3 keys, 

namely f irs 7 f f ^ ~ < " Nations, 

venerator, then usrng a key ma ^ °' ^ 

in the consolidated data "base ^ ^ 

35 found, a new one is created „ "° " S key is 

various mapping tables " int ° «» 
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The additional key mapping taWe necessary - 

to prevent a key from be i ng created twice » ° rd ~ 

in which the d^ fl ln the cases 

i-ne aata have not vet h P p n , . 

consolidated data base CD. The^oca^ aC ot 2 F 
5 generator is optional and serves merely to i y 
performance in the form of a cache. ^ ^ 

K/3 dat r rP ° SeS ° f SS ™ h ""-«ion between the OLTP 
R/3 data base OLTP-DB and i->^ , . ULTP " 

0 of the MS syste! t C ° nS ° lld «^ data base CD 

system, two components =^ 
"Request" and "Compare" Th. p Provided: 

a1:r to the c-tr::,— :-: 

allows particular- k,,~- luUda • It 

paxticuiar business obiects k~ 

downloaded from the Ob T P- R/3 database 
■ consolidated data base CD, and hence perlits t h V ' 
of the portable computers MC to be relUcat , 
the control of n,» «, replicated (under 

of the flow control FC) . The fi,,. 
criteria specified by a Request ar» ■ 
general fil ter criteria o£ ^ inTLIT ** 
that only one subset of the a T download, so 

initial download can be selected TheT^ ^ ^ 
can be started both i„ f lected - Th e Request component 
rted both interactively and in batch mode. 

The compare component downloads business dat, f 
°bTP- R/3 system. The differences resulting f 
comparison action descriK= -u r. resulting f rom the 

-e in the consoird^rda :\?r C D * * 

content to match the content of the oZ ZTl ^ 
OLTP-DB . in t-h< e . OLTP-R/3 data base 

xn this context , 

'•-serf. - update .. ..Deleted is s n t 9 Jred inf0rmati ° n 
structures. After the actual , " BD ° C 

changes are applied f -! comparison action. the 

°roer to maT it co C ° nS ° lid "* d d «a base DB in 

change information C ° nS1Stent " iCh th * <*TP-DB. The 
a inrormation is used to create pn. 

BDocs are used to replicate the Toc al datTb 

the mobile clients MC (under the ** L ° ° f 

control) 

uxie control of the flow 



- 32 - 



20 



25 



30 



35 



A few functions fundamental to the • ' • 
explained below by wa y of addition «• 

s I- Provision of primary Keys across ^ 

As explained above, it is important £or 
integration of offline-distributed J~ 
that a primary Key permitting unique Went f 
the data objects beyond the boundaries T t t °' 
0 systems which are fused °* ■ ^ data base 
the system. available across 

■ the explanations already" Len ^ ^"7° 

i e rr/e ^trr th * data — *~ « :r 

systems (source system), which ^ 
generally by A or r „ „w Ctl are denoted 

- respectL sy^l^c TZ^Z ^r K^ 

-^rr 1 ™ ^-r k : y ,of tL ---- 

-he Key aerator reads J" d " a 
table KMT and compared it witT 1 ^ k °' * *"* ™^ 

data record supplied by one of the " ^ ° f 
the primary Key of the source 

is already available in the Z K »> 
-pplied data record relates IT 

-ready existing entry. In this ~> f » 

primary key of the d^t- ■ - • associated 

cne aestination svst-^m / *~ 

« read from the Key mapp ing table It Id ** 
»to the empty f ield of the ^ « entered 

by contrast, the primary key suoolie* ■ 
« the Key mapping table KMT then a ne h " "° t 
being created (Insert) m th " 
module KGM creates f K« ' • 1E CaS6 ' a key 9 e "erate 

K.) and writes it to TT e ™ 
addition it i. \ Sy ■W" table kmt. In 

• x. entered into the empty data field. Th" 
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data record can then be uniquely identified in the 
destination system as well, and the keys of the source 
system and of the destination system are uniquely 
associated with one another. 

A practical way of implementing this principle in a 
data base system whose data objects - l ike the BDocs 
described above - contain a complicated structure of 
hierarchically structured data segments in the 
practical implementation is explained below. 

Figure 9 shows a very simple structure comprising two 
segments SI and S2 . The segment SI is one stage above 
the segment S2 in the hierarchy and is therefore called 
the father segment for the child segment S2 . m the 
case shown, the father segment is the root segment of 
the BDoc . 



2 0 If SS9ment 51 C ° ntainS * Primary key of the 

20 MS system and a primary key K R/3 of the OLTP-R/3 system 

Each of the keys is stored in one or more fields of the 

segment . 

25 711 "IT* alS ° COn " inS 3 Primar * *- 

25 stored rn one field, o£ the MS system and a key K„ 3 

(stored in three fields, of the OLTP-R/3 system. In 

addrtron. the fields of the child segment also contain 

the keys of the superordinate father segment, as is 

30 2 Clea I ^ SrrOWS bStWeen the . C "° segments. 

30 However, these fields have no key function, but instead 

serve as .foreign keys' for providing information 

TT^. ^ Se9ment struct «e. They thus indicate 

that S2 is a child of the segment SI. 

35 The right-hand part of Figure 9 shows an associated key 
mapping table, with the rows denoted by the arrowl 
indicating the keys of the segments SI and S2 
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Figure 10 shows a somewhat more complex field s- 
having a father segment SI ,root segment „ ' 
two hierarchically subordinate segJTtT S2a ^ ' ' 

the child generation, and a T S2b ° f 

5 «~*" aeration, which is . c^iTf " ° f ^ 
"a. By wa y of example, for a BBo c of t L 
^e, the segment si could contain the "customer- 
of the customer the Contain the name and address 

er - the segment S2a could ~~ • 
contacts for the = could contain the 

» -tact information /or \h " ^ 

numbers, business hours, etc i^'T'T ' teleph °« 
contain Information relating t * ^ S2b C ° Uld 

the customer. 9 t0 """hines installed with 

" IwTj^rone^ Se9ment COnt — «« «» case 

clarity, the LyTx 7 ^ S ^ of 

-r/ une xeys K MS and Kr /-» of f-v,<* *- 

systems, with the dependent system^ c " 
respective keys of th= » sterns containing the 

« ^eys. m turn the ' * " ^"'^ aS ^re ig n 

^nt-hand side of ZJZTlo T" "^"^ « the 
the keys of the two systems <* 

In practice, data objects of 1 = 
« can have very complicated .^JT" .T ^ 
interleaved hierarchical levell Z 

containing very large „^ ers ' ot ° ften 

addition, specific structural ellents areT ^ 
necessary in order amenta are frequently 

3 ° requirements. By wav 3 £ ° r Particular 

tne need to be ab^to acTe^ dat "T 
-cords quickly even though the y are t ^^ 
hierarchical levels, m these cases i "^ °" ^ 
store the required Key of a h' " eXP£dient to 
3= segment in a specific field of a ^"""^"v i°»ar 
of example, Figure 10 shows tLc thT 
c°oe Cl„ of the first data record 0 f the ^ 
-tared in the special field SF of the ' *" 

of the segment SI, f or 



- 35 - 



example in order to allow direct access to the most 
important contact of the customer coded in SI. Such 
structural peculiarities make carrying out the 
procedure outlined above very difficult in practice. " 

Such problems can be solved using the algorithm shown 
below. It comprises two program parts, called PASS-I 
and PASS- II. 



10 PASS-I: 

For all (defined) segments { 
For all data records { 
// Fill K MS // 
15 If (K MS = EMPTY) { 

Search in KMT (K R/3 ) 
If entry available { 

Remove K MS from KMT 
Enter K MS in BDoc 
} otherwise { 

Generate new K MS 



20 



25 



30 



Enter K R/3> K MS in KMT 
Enter K MS in BDoc 



} 



} 

// Fill MS father key // 

If (MS father key = EMPTY) { 

Position in BDoc father segment (R/3 

father key) 

Remove MS father key from BDoc Father 
Segment 

Enter MS father key in BDoc 

} 



35 } 



in PASS-I , the algorithm section headed by the comment 
Fill W is carried out for all defined segments 
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(i.e., for all segments for which key generation is 
required) and for all data records. This algorithm 
section first asks whether the field for the primary 
key is empty. If this is true, the key mapping table is 
searched under the available key K R/3 to determine 
whether an entry is available. If appropriate, the 
associated MS primary key is removed from the key 
mapping table and is entered into the. BDoc. 

If no entry for the sought K MS is available, a GUID is 
created as new MS primary key, and both the K R/3 and the 
K MS are entered into the key mapping table. In addition, 
the K MS is entered in the BDoc. 

Next, the algorithm section headed by the comment "Fill 
MS father key" is carried out. If the field for the MS 
father key is empty, the reading position is put into 
the father segment within the BDoc, specifically into 
the data record which contains the corresponding K R/3 . 
The corresponding K MS is then removed from the father 
segment and is entered into the foreign key field of 
the child segment. 

PASS-I is carried out a number of times until all the 
segments of the BDoc have been processed in the order 
prescribed by the hierarchy (starting with the highest 
hierarchical level) . 

Next, PASS-II is started. This is controlled by means 
of a table, called a FETCH table, which* is stored in 
the repository. This table describes filling actions 
which are not possible in PASS-I. These include filling 
with values from hierarchically lower segments (as 
shown in Figure 10) and filling with keys from a 
hierarchical level which is higher than the father 
level (that is to say, for example, two levels higher, 
i.e. grandfather). 
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15 



a«±e nas the following structure - 

• DestTbl: Destination Table 
- DestFld: Destination Field 

• SrcTbl: Source Table 

• SrcFld: Source Field 

s KR/3 ° r C ° ndition - accordance with the 
sample x = y 

An entry in the FETCH table creates - fir 

Algorithm representation for PASS-II: 

For all defined segments { 

For all entries in the FETCH table in which 
DestTbl = segment { 

20 , Read in ^lues from FETCH table 

If (Cond = r/3) { 

// Values within the BDoc 
Position in BDoc on SrcTbl (K R/3 ) 

Write SrcTbl -> SrcFld in DestTbl -> 

DestFld 
) otherwise { 

/ / Values from CD 

Position in CD on SrcTbl with filter - 
Cond 

Write CDSrcTbl -> srrPi^ ,• r> 
3 0 SrcFld in DestTbl -> 

DestFld 

} 

} 

} 



35 



fetch ?r; d N ;; t tr, che ~ - 

NSXt ' Case d ^tinction takes place. 
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If Cond = R/3 has been 

5 s ^«s. If the condiWon hlD th e destination 

values are being transferred ^ £ velue. 
fro- th * consolideted data bas / r c °; B °~ it-lf or 

within the data base CD h«- * SOUrce table 

thereof being trJ^itTe, ZT' ^ ™ 

- the destination segment in the "™ ° f 

2 • Data merge 

Another fundamental problem when fusin s diff 
15 base systems is that th= .o different data 

Particular typeo£d ?r ob h e cts irth aV : ilable * 
^"erent. B y way of examp e ^ W ~ 

-formation rel at in g to individuel cu 7 to T "* 
preparatory sales ri,=,- • customer contacts or 

20 .customer/ da I ob tor the 

"guired by an ERP t^ST^" * «* 

data object in an ERP « . nversel y< the "customer" 

- «- -11 c U sT om ::^ror t c sT„r n : inf °— - — 

began, which is not ™ • 7 business relations 

« which there are * ^ ^ «« '« 

data objects proc^ t ^ a ~ t - «"»^« in the 

With regard to the primary keys the , ■ 
above is advantageous. „ he « on f of *** l09 ~ explained 
30 the front-off ice Eystem Ms _ ^ namely 

<* the fused systems. while t ? ^ f VS *" and 
holds only i ts key Ks/j hlle Che hack-office system 

To enable the interch a nge of dat a • 
« arrangement to be , ln suc h an 

r rge procedure- IZ^^'^ ' ^ 
described with reference to p Procedure is 

following convention- 

yures 5 and H, using the 
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A- Data whlch exist only in the ^ 

Data which exist only in the OLTP-r/3 „ , 
•W Data which exist in hoth systL ^ " 

5 If data, as shown in Figure 11 f™ ,u 

provided as a Bv ,i- MS System ^ 

* a as a system-specific data object ( B no„ <= 

transfer to the OLTP-R/3 system it * f ° r 

and K MS as keys. x n the OLTP ada\ " 

^ UL.TP adapter OLTP-An ^ 

MS x. distributed and parked by the BAPI ^ 
10 Next, the OLTP adaot^r caller BC. 

adapter transports the rest 
information O, = n H • of the 

i^Mix and K MS into the OLTP d/i 

-V o, the sou.ce syste m K „ s ^ rlZ^ 



15 



destination system OLTP-H/3 and s parkedTth ^ ^ 
area Additional MS-Data AMD. ^ mem0ry 



Next, the D MIX data is complemented with add^ ■ , 
Do which is necessary in order to addltlon al data 

data object in the L I Process the created 

additional data r s natl ° n ( ° LTP ^3) . This 

values) for the corresTT " ^ ^ 
cne corresponding data fields. 

Normal processing is then carried out in ^ 
system. The data is checked as _ ^ ln the °^P-R/3 
losing routine cu stomal th ^ ^ 
stored in the data base OL T P _ D B d " t ™ t "» S — m and 

In connection with the logging an « „ • 

which the event distr-iK . * 15 tri 99ered 

-mgs, to tti amongst ° th - 

data from the ^i^^^t^ 
comprises D R/3 , D Mix and re . f! reCeiVed 

inserts the parked MS key 1 \ « ^ RS 

-ch is not relevant to^h^ *» 
« then transferred into the MS ! PaCk<2t 

*. and KR/3 . Within £ J\ZT Z 
agent RSA adds the parked data I """^ SaVe 

full BDoc containing the data ^ n^ 111 ' "° ^ ^ 

available for further processing r ^ ^ Kr/3 " 

processing Un particular, for 



25 



30 



10 



consolidation in the ri*t-= w 

replication to the Mle ^ C ° f » «*.^«t 

cne mobile clients MC) . 

This data merge procedure takes „i » 

from the MS system is unoJ „ whenever data 

yscem is updated mto the OLTP-r/t «, - 
In the case of data chances -in ^ system, 
(delta download), part of 1 • ° LTP " R/3 SyStSm 

starting with the w, dure i s executed 

-ing able to ^J^Z ^ ^ L." ^ ^ 

generated by the kev ™ CaSS ' ifc is 

y une key generator KG i r. *-u 
explained above. he ma nner 



3 - Download 



5 



5 A fundamental aim nf <-v 

have to be ma intained separate, * t0 
data present in th e cor date ^ 
rendered jointly usable . By £" to be 

f — f «« *yste m needs to be able To^ 1 " 3 ^ 
rel a tin 3 to cu s to m er and product info a<=CaSS 

E KP bao k -o £ti oe s^te/ot *" 

a ) Initial download 

Hence, the f irst object 

those data in an «i „ 15 to transmit 

SrSten, <so U rce sy st e : rtn tt iStin9 

whicb is also retired ^^Z^™ 

system) £rom the ^ tem ln case MS 

-Pe or an i ni ti al ^^"V^ E ^ «- 
Problem solutions belo, context, the 

of the present We^ol . ^ 

The volume of data in «-v, 

•caned OLTP - R/3 sy n sc r b^r^rr^r system 

— ation or tne S eneral nature, TsVeraZ ^ 
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large. For this reason, means have to be provided for 
specifying more precisely the data which is to be 
interchanged with other systems. Within the scope of 
the invention, this is preferably done by filtering. 

5 

For the filtering, the extractors provided by the OLTP- 
R/3 system and described in conjunction with Figure 7 
are used. In this context, a particular feature is that 
the use of the extractor master provides a standardized 

10 interface to the MS system via which all enquiries in 
the MS system pass. The data are thus filtered by 
virtue of the destination data base system MS 
transmitting the requests for data that it requires via 
a standardized interface to extractors which are 

15 implemented in the source system OLTP-R/3 . 

Another problem is that of permitting initial download 
in a reasonable time. This is not possible using the 
means which are usually available in back-office 

20 systems, because these means are not equipped for rapid 
transmission of very large volumes of data. This 
problem is preferably solved, within the scope of the 
invention, by providing the specific data containers 
called bulk-oriented BDocs which are explained in more 

2 5 detail above. 



Finally, a problem of initial download is that of 
ensuring that the data transmitted to the destination 
data base system correspond to a precisely defined 
state of the source data base system at a defined 
instant (a snapshot) . Conventionally, this problem is 
solved by blocking changes to the source data base 
system during initial download or - to the extent that 
changes are permitted - using special instruments of 
the source data base which, however, preclude any 
database independent operations in the initial 
download. 
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To solve this problem area, the invention proposes a 
procedure which is called online sync procedure below 
and is explained with reference to Figure 12. In this 
case, the extractors implemented in the source system 
OLTP-R/3, which are addressed via the extractor master 
interface EM - controlled by filter definition stored 
in the destination system MS -, operate normally, 
reading and outputting in blocks, and are not aware of 
the dynamic data change in the source data base. The 
bulk of the data required by the destination system is 
thus transmitted on the path denoted by the arrow IL 
(initial load) . 

In parallel, however, the aforementioned delta handling 
is also executed by means of the results sender RS . 
This places changes which arise in the source system 
during initial download into a queue. In contrast to 
normal delta download operation, this queue is not 
unblocked, however, but is blocked over the duration of 
initial download (queue stop QS) . When initial download 
has ended, the change queue is unblocked and the 
changes made during initial download are transmitted to 
the destination system MS via the delta download 
channel symbolized by the arrow DL (delta load) . This 
results in a consistent "snapshot", in relation to the 
instant at which the initial download ended. 

b) Delta download 



For the delta download function also, reference is made 
to the explanations given further above (particularly 
with reference to Figure 5) and for the data merge 
procedure. The object in this case is to supply all 
systems connected to a source data base system A with 
respective changes in the course of operation after 
initial download. 
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The function is provided in two substeps : 

a) notifying the source data base system regarding 
changes made, and 

b) incorporating the change and editing it and then 
transferring it to the destination data base 
system for further processing. 

Normally, change pointers are used for the purpose of 
notification about changes made. This has considerable 
disadvantages, however. First, it is necessary to 
provide the application of the source data base system 
with a change pointer for each possible change. This is 
usually not possible for all data objects, but is at 
the least very complex and is a critical cause of 
error. Secondly, changes are transferred only at 
prescribed time intervals. 



To solve this problem area, the invention preferably 
uses event technology. Integrated into the routine for 
incorporating a change in the data base OLTP-DB of the 
source data base system is the creation of an event. 
The event distributor ED is used to call function 
modules maintaining a subscription for the event when 
the event occurs. These function modules include an 
appropriate module of the destination data base system 
(in Figure 5, a component of the result save agent 
RSA) . Hence, the OLTP-R/3 adapter of the MS system (in 
general terms, that is to say a module of the 
destination system) almost immediately receives 
information about any change in the source data base 
system which is relevant to the destination system. 

The subsequent transmission of the change from the 
source data base system to the destination data base 
system is carried out using the filter criteria FD 
(Figure 12) stored in the destination data base system, 
which has already been discussed. The data are then 
edited using the data merge procedure described above. 
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35 



and the procedure that- 

above is used to generate a " beSn de =«ibed 

generate a cross-system primary key . 

Another particuiar f eature of 
5 <^"icular ly in the case ^ "ansfer is that 

-eld determination, as f™' — 

To minimize recioror^i ~ 

l« g e number of users aT""" 9 ° £ Ch "— «- by a 
10 ^Pendently. it is advanta'elTto^ 

changed fields of the respective dat ' ^ thS 

called net-field tranw * data records . This is 

transmission. ERP back n rt- 
such as the OLTP- R/3 system • baCk " office systems, 
are generally able to ' ln Partlcula r. however, 

S field- basis! i e th COTOl " ac e «ly on an 

"cords with all- the fi h e T d ~< ~* entire data 

« therefore transferred to the destinat 
on an all-f ield basis via ^ SySt ™ « 

12) if such a transfer „ DL (Fi 9 u " 

> —Its sender RS In ac „ ^ trl «~«* by the 
embodiment of the in^T"^- ^ 
overcome by virtue of the de= f • dls advantage i s 

<*• data base service CDS for ^ 

CD, determining the actual h C ° nS ° lidated 
b, comparison with the content of " ^ 

base CD, and entering only the °° nS ° lld ated data 
subseguent processing on a net-f tldls"" . ^ 

Th ? SPeCific »ay in which this occurs is , . 
reference to Figu res 13 and u ° CUrS ls explained with 

To support the net-fi»iH ,. 

the BDocs (i.e.. of the d a t r a a T iSSi0n ' Se9menCs ° f 

*»■ base system, contain a ^eT wT T ^"""^ 
changed fields. This fi»iH • h "fleets the 

By way of example WL""^ ^ 
and. in binary representatio^ ^ T- ^ ™" 2 > 
-tains .expediently stored i n Z io L ^ 

f °rm) a which 
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corresponds to a f,' a ij , . 

field information FIN is , h lnformac "n SBP to the 

13. Deletions are also , « figure 

cure also indicated 

5 ! aSe **™> * way of example, the f ^T' ' ^ 
fields 1 and 4 has been d the * x-ld content of 

the field content of fields 2 and 8 h k " C " ) ' 
The field content of ^. ^ • • S been dieted. 

ncent of the additional field q RP „ 
a relevant part R, whose number Sld comprises 

10 the number of fields an* corresponds to 

■L-Lt;±as, and a non-re1ou an) . 
is ignored. relevant part l, which 

If data records are transferred to th- ' * • 
^se system on an all-fi eld ba ^ tot ™t:±on data 
15 ad.-ust.ent in line ^ *™ ^ an 

destination data hase s y ste m MS This adi^t ^ 
made in the data • adjustment i s 

aata base service CDS nf t-u 

and is shown graphically in ^ ^ CD 

data record Dl i«= a Therein, the 

2° transmitted on an Jl-«. ld ™' °' 3 
«-ld oontent -X- . Tna data ^ 

the data record with th* „ compares 
-red in the ^ ^ c 7™^ ^ W 
the field „ ith the content J"^^ that only 
" A cc°rdingly, the data record D2 is changed, 
contains only th « „ generated, „ hich 

corresponding send bTt h a, C K an9e<3 inf °™«"n. The 
- .eld contents 1^^:° ^ ~ ~< ° f 

30 c) Synchronization 

Semantic integration in t-h« 

introduction means L re than ' ~ Plained in th * 
between systems. ^ er <* data 

3S appl ication Korks n h - e P-"ble. the „ ay the 

~ ~ *. - cent - .^r:: 
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repository of the respective data base system and map 

^^-^zr^r- — - 

integration should aiso Lvo^ r e ^ 

cne OLTP-R/3 system, these are t-ho 

customizing tables' „ tables,. changes to the 

customizing tables are indicated in the OLTP R/3 ! 
neither by change pointers nor as events I 
10 Accordingly, a replica of these data In a dss "T' 
data base system suc h as the M s system ^ 
if there is no suitable update mechanism availablt 

15 ^ C ° Permit ° n90in9 s ^=hronization of the data 

15 state between a source system and a destination sy^em 
- such cases too, the aforementioned -RegTsf a^ 
"Compare- components are used The „ t 
mechanism produced thereby is e^llned ITth refe^nc" 
to Figures 15 and 16. rence 



doled arMtlry V ^ - 
a arbitrary business objects from the OLTP-R/3 

25 : " ^ MS * 1- I- used which s 

tie iirci: 1 extraccor ge ana iE * - 

definitiln F 7 "'^ " °" b ^ ° £ «» «"er 



Before the data downloaded in thi . 
30 incorporated into the consolidated data bas" 

compare module, denoted by COMP i„ V * 

and allows only data ^ ch ^ ^ CD 

" Pass, in addition t aCtUaUy Cha ^ ed «» 

-** are n^ger 2^ iTT^ ^ ^ 
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The algorithm used for «-H,-=, 

with reference to Figure 1 6 ! ^ 
Oata received rroj th 0^3^""^ ^ "» 
respective correspond^ tJ^L'T" 
5 first provided in . " baSe CD *» 

81. when the corresoo d " S2 — 

corresponding table is selects * 

data base CD, the data is fil^ „ l6Cted from the 

records which are contained 1 911 the 

—re 16, the records TL 2 T ^ "* ^ 

- other records also ^ ^™ ^ 

^ta. A further restriction for ^ MS-specific 

ensures that the m « m « transmission 

which is also availabT T" " ^ 
also available m the OLTP-R/3 system. 

15 The contents of the memory areas si 

subsequently compared by choosing one of the t M ™ 
reference, with this table w ^ 35 

steps from its " . PSSSed through in 

its beginning to the enrf „ ^ 
corresponding entries being sought in , h ^ 
20 m this case it it? „ 9 " the ° ther table. 

' lt: is advantageous for- * 
reasons, f or th«= Performance 

table which contains t T nCe ^ ^ th " —V 

—re l6 . the cable t ^ ° f <i" 

^sis of the result of ^ — «> ■ °n the 

25 actions are taken, such as: C ° mp « ls °". appropriate 
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Create new entries: "I" 
Create net-field entries: "U" 
Create deletion order: "D" 

The algorithm can be represented as follows: 
For all entries in SI { 

If available in S2 { 

Create new entries ("I") for all previous S2 
entries not affected 
If changes 

Create net-field entries ("U") 

} else 

i 

Create deletion order ("D") 

} 

4 . Upload 

As explained, it is a fundamental element of semantic 
integration of data base systems for it to be possible 
to make data entries and changes not only in one, but 
in a plurality or all of the interlinked data base 
systems. By way of example, it must thus be possible 
for sales representatives to input new data (for 
example a new order) into their portable computers at 
the customer's and for this change in the dataset to be 
preserved in the data base OLTP-DB. 

Changes at the level of the mobile clients are 
registered by the transaction layer described in 
conjunction with Figure 2, via which layer the mobile 
clients communicate with the MS system and their own 
local data base LD. When the portable computer is 
linked to the middleware server MS, the changed data 
are transferred as BDocs and are also transmitted to 
the back-office system OLTP-R/3 . The components used 
for this purpose have been explained with reference to 
Figure 5, and the data merge procedure taking place in 
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A fundamental requirement for such a data upload is the 

or o ha h " C ° nfUCtS beC "-" data entered 

•lata lf„t " l0Cati ° nS ' ^finition ol 

data maintenance ascendencies-. „ hich permits ^ * 

be changed only at particular locations in th 
) composite system in each caS£ , would « 
adequate integration. Even the LOW (last oL 
Procedure used in «n y appl ications is Z ^LTT 
-ch a composite system which includes the d at a of 

back-office system. ta ° f an 

For this reason, the present invention uses a „„ , 
conflict resolution strategy called LS C ,le ng sysZm 
concept) Th^ t co ~ Iiy system 

v-;. ine LSC procedure defines a m^ = ~- 
(FS) for each ■ * mana Sing system 

v ^ / j-ux eacn data obiect ai i , 

J ^' AX1 the other systems in 

rrr s ~ zrr — (gs > ^ 

must f lrs t be confirmed by the pq 
fundamental difference " A 

confirmation functioT ,."^^1 Tn^ 
case croc5ec *-v,~ , . m - Llon m this 

crosses the application boundaries ^ 
resolve conflinhc v. _ anes and serves to 

ve conflicts between systems whose structures are 
not compatible. cures are 

Implementation of the Lqr * 

-notions which are ^J^T ^ 
In the example described here t-ho vro 

-naged system for ail data oh 'acts 2 ^ 
must be able to satisfv f , managed system 

- The following requirements: 

status , ^ ^ dete « the confirmation 

status (accepted, rejected, open, of the data at 
all times when they are displayed. 



I 
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The user must be able CQ access 
values again if the data which he has ch 
rejected. v u is 

The data object must not be blocked until a change 
has been confined, i.e.. a plurality of changes 
to the same data object which are to be checked 
must be able to be made in succession without 
havxng to wait for the end of the previous check 
Data consistency in the entire composite system 
must be assured. 



15 



These retirements can be satisfied, in particular, by 
two function modules, called a pending counter ,PC, ano 
an inbox (IB) . 



20 o: 



The pending counter is a char,4, field which can be 
ound m any table involved in the data interchange 
(that is to say in any segment of the BDoos). This 
field is used to define the current confirmation state 

by tte a" i- " * """^ is « *»t- 

by the a P pli Cat i 0n program in order to visualize the 

confirmation state of the dat» r 

screen . the data " £ <" example on the 

25 The pending counter has the following forms- 
"0": OK 

P<n>: Pending ,. open, not yet confirmed,, where <n> 
increments the number of changes as a reference 
counter 

30 F<n>: Data record is in the error state 

The Pending counter is incremented with each change and 

systt !m 3931,1 UP ° n * «- Paging 

system, until it is at »0" am<n T . 9 

3S decremented in the case of rejltioT but an 

instead of a "P". et 
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To assure data consistency in the entire system, it is 
• necessary for the original data state to be restored in 
the managed syste m if changes are not accepted ,rol, 
back,. This is preferably done by virtue of 

™ 91nS SVStem (in —Pie. the OLTP- R/3 system, 

sending back the -image of the previous state- {bstore 

awi Bl t c :r ined in the data ° b - ct - " 

above - to the managed system at the same time as the 

rejection. A roll back car, 
,„.... ack can thu s be effected bv 

10 introducing the original state. 

However, a disadvantage of this procedure is that all 

he usefs changes in the respective data object 
thus overwritten, xf. by „ ay of example. an order 
contammg more than 100 items is involved which has 
possibly been reacted on account of a comparative ^ 
slight inconsistency, it is necessary for the data of 
the incorrect, and therefore unaccepted, data object to 
be made available again to the user who mads the 
change This is done using the inbox. The user can then 
conveniently adjust the entries and make them available 
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The operation of the pending counter and of the in box 
is shown in Fi gure 17 with ^ aid q£ 

this case the column headed LD symboli.es the content 

Ldio^ng 10 :: rtL : a £ se th wich a - p -^ «•» 

s tne status of the pending counter PC the 
primary key field K and the three data fields D . 

m a first step, the content of the middle data field 
2-. CMtainS ° nly Cha " 9ed information 

In the next step, two data fields *r-o v, 

chan.ed information items ^ £^ ^ 

transmitted as a BDoc m t-h. * ,u likewise 

bdoc. m the fourth step/ confirination 
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of the first change is received, and confirmation of 
the second change is received in the fifth step. The 
pending counter PC indicates the respective 
confirmation state. 

In the sixth step, a change which is unacceptable to 
the managing system is made, which is marked by a 
symbol in the form of a star. This change is rejected 
as error message "E" , which means that the state before 
this change is restored in the eighth step. At the same 
time, the "rejected" changed state is placed into the 
inbox, so that the user can continue to work on it. A 
permissible change in the first field, which has been 
made in the meantime in the seventh step, is confirmed 
15 in the ninth step. 

The before images are created under the control of the 
flow control of the MS system using a reject service. 
This reject service uses a flag which is set in the 

20 header of the BDoc to check whether the entire BDoc has 
been confirmed or rejected. In the case of rejection, 
the reject service extracts the entire data of the BDoc 
from the consolidated data base CD and makes it 
available within the BDoc as before images. If the 

25 entire BDoc is accepted, then the reject service checks 
its partial segments for their status. If a partial 
segment is rejected, its contents are likewise 
extracted from the consolidated data base CD and are 
made available in the before images. 

30 

The managing system must be capable, within the context 
of the LSC procedure, of checking inbound data and 
rejecting it if required. This function is usually 
implemented in back-office systems. Other functions 
3 5 which are also important in this context have already 
been described. These include data complementation in 
the case of acceptance, which has been described in the 
context of the data merge procedure, and transmission 
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of the primary key of the managing system, which has 
likewise already been described. 

5. Extension and variations of the composite system 
5 illustrated 

The example illustrated has, in essence, described data 
interchange between the middleware server MS, which 
forms the central computing unit in a CRM front-office 
10 system, and the OLTP-R/3 system as an example of an ERP 
back-office system . 

The procedures and algorithms described can also be 
applied to other cases, however. In particular, the 

15 middleware system MS can use the procedure described to 
communicate with other, different data base systems, 
whose logical structure has overlaps, at least to an 
extent, at the level of the processed objects, whereas 
their structure is incompatible at the level of program 

20 implementation. By using the procedures described, the 
MS system can thus be used as a switching system 
between different external data base systems. 



